On Thu, Mar 27, 2014 at 10:58 AM, Benjamin Piwowarski <[email protected]>wrote:
> Just my two cents here - I don't want to reheat the debate - but I find it > confusing just for one reason, terminology : the 2.2-staging branch is, at > least for me, the develop branch (where all new commits should happen), and > then the different branches (master = 2.1, 2.1.1-staging) are managed by > the release manager. I would find it much more logical to have : > - master as the main development branch (I know the argument about > freezing, but I believe this does not hold, since anyways people can > continue to develop wherever they want with git) > - then releases branches (releases/2.1.0, releases/2.1.1) which are > managed by the release manager that can pick commits from the > develop/master (or ask the committer to commit in the release branches). > Branches can be cascading (like 2.1.0 is merged into 2.1.1) or not, again > this is managed by the release manager. > > I know it puts (maybe) more burden on the release manager (I am not fully > convinced by this though), but this could reduce the confusion. > People are so confused by adding 1 extra branch only. I don't want to turn over everything completely to make it "less confusing". For every change there are people fighting against the change at all, and now you want to take it even a step further. It's driving me mad. > There is the case of translations which are always asynchronous since they > start when coding has stopped, but this can follow a slightly different > logic - working only in release branches which are then merged to the > develop branch. > Again, I'm not going to make it more complex. > > Just one last note about the freezing/development process : > - I find it very difficult to understand from the trac interface what is > the current state of the project, what are the bugs that need to be fixed > and what are the bugs which are already worked on by some people. > I don't know what you mean by "current state of the project". The bugs that need to be fixed have a milestone. People don't tell others on what they are working, so no interface will ever provide that information. Reading the lyx-devel list might be your only help. > - this is somehow due to trac lagging against other collaboration > interfaces that make it much easier to understand what a patch is doing by > allowing to visualize it, to comment directly the changes before pulling > the changes. I know there had been discussions about it in the past (like > switching to github if I recall well), but I don't remember what was the > outcome; I could work on switching to such a platform (there is also an > open source alternative, gitlab), there are some scripts that exist on the > Web for this that could be adapted. > I guess we don't want to switch. > - it would be great also to have some automated build processes (and > tests?) to reduce the likeliness of a bug being introduced in the > repository. I could do this for the OS X platform (have to check how much > work this is first). > Well, testing would be very welcome. For automated build processes, we need access to computer power. I think some services are provided, but without testing it makes not much sense. Vincent
