> On 10/13/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > And, it would have been great if this change had been discussed on the > > dev ML before being committed. I know I haven't been really active > > these last weeks, I've been quite busy with school and other projects, > > but I'd still like to have the opportunity to give my opinion before > > such a change happens. > > More generally, there has been a lot of important changes recently in > > Etk internals, some of them are great, but there also have been changes > > that I really don't like. I would have appreciated if you (i.e. > > developers who made these changes) had discussed them publicly and > > *waited* for my response before committing them.
I agree that changes need to be discussed if they are considered to be "major" changes or ones that affect the core of Etk. My response will be continued after Gustavo's reply as it also responds to his email. On 10/13/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > This specific change was not discussed in open, but others, like > Etk_Signal, were and at least CodeWarrior said: go for it. Before we > were keeping those changes in GIT branches at http://staff.get-e.org > and CodeWarrior wisely requested us to keep these changes in CVS to > avoid fragmentation. I can see where Simon is coming from regarding major changes being submitted to Etk without him getting the chance to be a part of the discussion. I can also see where Gustavo is coming from regarding discussing these changes both online and on the mailing list. I personally believe that all major changes should be discussed and reviewed by those who work on Etk. We have to keep a few points in mind though when deciding how to do things, and when it is OK to submit a so called major change to CVS. 1) Simon, although you want to be part of the discussion and review process prior to the inclusion of major patches to Etk, remember that you have not been online very often lately. I am not saying that developers wishing to submit major changes to Etk should not wait for you at all, they should, but they can not wait too long. Since the INdT is using Etk for something more than just a "fun hobby application" like most of the other code using Etk, they can not spend a lot of time waiting for their code to be reviewed and discussed. This does not mean that they have to check their code into CVS the next day after sending a public announcement to the list about it. This does mean however that they can not wait 2 or 3 weeks every time they have a patch pending review. They can keep their own tree only for so long, at which point they should merge it into CVS to avoid all sorts of conflicts and incompatibilities that might arise. So to summarize this point (which was brought on earlier when we were discussing the whole EFL delays that occur with raster's patch reviews due to his tremendous email backlog), a fair period should be given after a patch is submitted to the ML or Bugzilla. What is this period? A week? 2 Weeks? We should agree on that as one of the outcomes of this discussion. > We (INdT) choose ETK over EWL because it was easier to get our > requests done and accepted, but we said (at least to CodeWarrior) that > we wanted some things changed. We really want to cooperate and build a > better platform together, but if you don't want these things in, we'd > have to keep a separate branch/fork with changes you still haven't > accepted... this will be painful for everybody. :-( 2) Maintaining a fork or completely separate development branch should not be something we even consider. Again, patches need not be submitted to Etk directly, nor should they have to wait a month before going into CVS. Remember that CVS does not mean stable, nor does it mean release. So if something does make it in there that is later determined to be a "bad idea" then we can always roll it back. That's one of the major advantages of version control. > So, when will you be back online? and which development approach would > you like (separate code bases or development in CVS)? > Although this question is directed to Simon, my opinion on this would be that we should continue to work on our current CVS, but we should set some rules as to how major changes are added. It should not be difficult to abide by the rules we set. If for some reason something has to go into CVS and is deemed a "rush commit" because it added something needed right now or fixes something (but is not entirely the best approach) we can always choose to fix it later, or revert it and find a better approach to do it. Etk is Simon's baby so to speak, so I can see and understand his point of view regarding having a say in what happens. Etk is also being used by a team that is developing industry grade heavy duty software, which means they will want certain changes and additions made, and they can not wait for a long time for their code to be part of Etk. Finding a middle ground on which we all agree according to a small set of fair rules is the solution to the current issue that we have. Lets decide what is best for all of us, and develop Etk further turning it into a mature stable library that can be used and developed by its current developers and those wishing to work on it for professional applications. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
